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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



,rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; Configuration Management (CM), as identified 
below: 

32.621: "Generic network resources Integration Reference Point (IRP): Requirements". 

32.622: "Generic network resources Integration Reference Point (IRP): Network Resource Model 

(NRM)". 

32.623: "Generic network resources Integration Reference Point (IRP): Common Object Request Broker 

Architecture (CORE A) Solution Set (SS)"; 

32.624: "Generic network resources: Integration Reference Point (IRP): Common Management 

Information Protocol (CMIP) Solution Set (SS)". 

The interface Itf-N, defined in 3GPP TS 32.102 [2], is built up by a number of Integration Reference Points (IRPs) and 
a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the IRPs 
is defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. 
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Scope 



The present document (Generic Network Resources IRP: Network Resource Model) defines an Integration Reference 
Point (IRP) through which an IRP Agent' (typically an Element Manager or Network Element) can communicate 
Network Management related information to one or several 'IRPManagers' (typically Network Managers). 

The present document specifies a generic Network Resource Model, NRM (also referred to as a Management 
Information Model - MIM) with definitions of Managed Object Classes. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs. In addition to the subject IRP, it is expected that IRPs will be defined for functional areas like 
Security management. Software management. Network & Service provisioning, etc. An important aspect of such a split 
is that the Network Resource Models (NRMs) defined in different IRPs are consistent. The Generic Network Resources 
IRP here provides a base for all resource modelling. 

To summarize, the Generic Network Resources IRP main purpose is to define a generic Network Resource Model that 
constitutes a base from which other (more specialized) resource models can inherit or have associations with. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and Definitions". 

[5] Void. 

[6] Void. 

[7] ITU-T Recommendation X.710 (1991): "Common Management Information Service Definition 

for CCITT Applications". 

[8] Void. 

[9] Void. 

[10] Void. 

[II] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 
Integration Reference Point (IRP): Information Service (IS)". 

[13] 3GPP TS 32.300: "Telecommunication management; Configuration Management (CM); Name 

convention for Managed Objects". 
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[14] 3GPP TS 32.600: "Telecommunication management; Configuration Management (CM); Concept 

and high-level requirements". 

[15] Void. 

[16] 3GPP TS 32.642: "Telecommunication management; Configuration Management (CM); UTRAN 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[17] 3GPP TS 32.662: "Telecommunication management; Configuration Management (CM); Kernel 

CM Information Service (IS)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.600 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently however, all (non-containment) associations are modelled by means of reference 
attributes of the participating MOs. 

Information Object Class (IOC): Within the context of all IRP IS specifications, IOC is the term used instead of 
MOC for a managed object class. MOC is used on the SS level. See also the definition of Managed Object. 

Managed Element (ME): An instance of the Managed Object Class ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. See also the def. of MO in 
TS 32. 101 [1]. The MO is instance of a MO class (MOC) defined in a MIM/NRM. This class, within the context of this 
Information Service specification called Information Object Class (IOC), has attributes that provide information used 
to characterize the objects that belong to the class (the term "attribute" is taken from TMN and corresponds to a 
"property" according to CIM). Furthermore, an MO class can have operations that represent the behaviour relevant for 
that class (the term "operation" is taken from TMN and corresponds to a "method" according to CIM). An MO class 
may support notifications that provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 

(3) a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 3.1 depicts the relationships 
between a Name space and a number of participating MOs (the shown association is of a non-containment 
type) 
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Figure 3.1 : Relationships between a Name space and a number of participating MOs 



Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.300 [13]) restricts the 
name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AUG Authentication Gentre 

EG Border Gateway 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DMTF Distributed Management Task Force 

DN Distinguished Name (see 3GPP TS 32.300 [13]) 

EIR Equipment Identity Register 

EM Element Manager 

FM Fault Management 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMSC Gateway MSC 

GPRS General Packet Radio System 

HLR Home Location Register 

IDL Interface Definition Language 

IOC Information Object Class 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

lub Interface between RNC and Node B 

LDAP Lightweight Directory Access Protocol 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MIT Management Information Tree (or Naming Tree) 

MO Managed Object 



£75/ 



3GPP TS 32.622 version 5.4.0 Release 5 



ETSI TS 132 622 V5.4.0 (2004-06) 



MOC Managed Object Class 

MOI Managed Object Instance 

MSC Mobile Services Switching Centre 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

OSI Open Systems Interconnection 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.300 [13]) 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

SMI Structure of Management Information 

SMS Short Message Service 

SMS-GMSC SMS Gateway MSC 

SMS-IWMSC SMS Interworking MSC 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

WBEM Web-Based Enterprise Management 

XML extensible Mark-up Language 



Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 

The following defines the meaning of Mandatory and Optional IOC attributes and associations between lOCs, in 
Solution Sets to the IRP IS defined by the present document: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 

• The IRP Agent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRP Agent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that the IRPManager, even though it is not required to have knowledge of vendor-specific extensions, 
may be required to be implemented with an awareness that extensions can exist and behave accordingly. 
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Modelling approach 



See 3GPP TS 32.102 [2] clause 10. 



6 Information Object Class (IOC) definitions 

6.1 Information Object Classes 

6.1 .1 Imported Information entities and local labels 



Label reference 


Local label 


3GPP TS 32.1 1 1-2 [1 1], notification, notifyAckStateChanged 


notifyAcl<StateChanged 


3GPP TS 32.1 1 1-2 [1 1], notification, notifyChangedAlarm 


notifyChangedAlarm 


3GPP TS 32.1 1 1-2 [1 1], notification, notifyClearedAlarm 


notifyClearedAlarm 


3GPP TS 32.1 1 1-2 [1 1], notification, notifyNewAlarm 


notifyNewAlarm 


3GPPTS 32.1 11-2 [11], notification, notifyComments 


notifyComments 


3GPP TS 32.662 [17], notification, notifyAttributeValueChanged 


notifyAttributeValueChanged 


3GPP TS 32.662 [17], notification, notifyObjectCreation 


notifyObjectCreation 


3GPP TS 32.662 [17], notification, notifyObjectDeletion 


notifyObjectDeletion 
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6.1.2 Class diagram 



6.1.2.1 



Attributes and relationships 



This sub-clause depicts the set of lOCs that encapsulate information relevant for this service. This sub-clause provides 
the overview of all information object classes in UML. Subsequent subclauses provide more detailed specification of 
various aspects of these information object classes. 

Figure 6.1 shows the containment/naming hierarchy and the associations of the generic information object classes 
defined in the present document. 
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<<lnformationObjectClass» 
Top 
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«lnformationObjectClass» 
VsDataContainer 



NOTE 1 : ManagedElement may be contained in either a SubNetwork or an MeContext instance (also shown by the (xor} 

constraint), or have no parent instance at all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: Each instance of the VsDataContainer shall only be contained under one IOC. The VsDataContainer can be contained 

under lOCs defined in other NRMs. 
NOTE 4: If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or 

indirectly contain all the other SubNetwork instances. 
NOTE 5: The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 

instance". 
NOTE 6: ManagementNode shall be contained in the root SubNetwork instance. 

NOTE 7: If contained in a SubNetwork instance, IRPAgent shall be contained in the root SubNetwork instance. 
NOTE 8: For a clarification on the choice of containment of the IRPAgent (since it has three possible parents), see the def. of 

IRPAgent. 

Figure 6.1 : Generic NRIU! Containment/Naming and Association diagram 
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Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses 
its containment hierarchy. As an example, the DN of a ManagedElement instance could have a format like: 

SubNetwork=S weden,MeContext=MEC-Gbg- 1 ,ManagedElement=RNC-Gbg- 1 . 
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ManagedFunction 



«lnfomationObjectClass» 
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NOTE 1: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 2: Each instance of the VsDataContainer shall only be contained under one IOC. The VsDataContainer can be contained 

under lOCs defined in other NRMs by virtue of inheritance from the GENERIC NRM. 

Figure 6.2: VsDataContainer Containment/Naming and Association in GENERIC NRM diagram 

The VsDataContainer is only used for the Bulk CM IRP. 
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6.1.2.2 Inheritance 

This clause depicts the inheritance relationships that exist between information object classes. 
Figure 6.3 shows the inheritance diagram. 
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Figure 6.3: Generic Networl< Resource IVIodel IRP Inheritance Hierarchy 

6.1 .3 Information object class definitions 
6.1.3.1 GenericIRP 



6.1.3.1.1 



Definition 



This IOC represents the IRP capability associated with each IRPAgent. This IOC cannot be instantiated. It is defined for 
sub-classing purposes. At least one instance of a sub-class of GenericIRP shall be present for every IRPAgent instance. 



6.1.3.1.2 



Attributes 



Table 6.1 : Attributes of GenericIRP 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


iRPId 


M 


M 


- 



6.1.3.2 



6.1.3.2.1 



IRPAgent 



Definition 



This IOC represents the functionality of an IRPAgent. It shall be present. For a definition of IRPAgent, see 3GPP 

TS 32.102 [2]. 
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The IRP Agent will be contained under an IOC as follows (only one of the options shall be used): 

1 . ManagementNode, if the configuration contains a ManagementNode; 

2. SubNetwork, if the configuration contains a SubNetwork and no ManagementNode; 

3. ManagedElement, if the configuration contains no ManagementNode or SubNetwork. 



6.1.3.2.2 



Attributes 



Table 6.2: Attributes of irp Agent 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


iRPAgentId 


M 


M 


- 


system DN 


C 


M 


- 



6.1.3.2.3 



Notifications 



Table 6.3: Notifications of irp Agent 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyPotentialFaultyAlarmList 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 





Note that these notifications are issued based on occurrences on the IRP Agent IOC and not on occurrences on other 
IOCS. 



6.1.3.3 



ManagedElement 



6.1.3.3.1 



Definition 



This IOC represents telecommunications equipment or TMN entities within the telecommunications network that 
performs Managed Element (ME) functions, i.e. provides support and/or service to the subscriber. 
An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 
monitored and/or controlled. MEs may or may not additionally perform element management functionality. 
An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 
"Network Element". 

A ManagedElement may be contained in either a SubNetwork or in an MeContext instance. A single ManagedElement 
seen over the Itf-N may also exist stand-alone with no parent at all. 

The ManagedElement IOC may be used to represent combined ME functionality (as indicated by the 
managedElementType attribute and the contained instances of different functional lOCs). 

Single function ManagedElement IOC instances will have a 1..1 containment relationship to a function IOC instance (in 
this context a function IOC instance is an instance of an IOC derived from the ManagedFunction IOC). Multiple 
function ManagedElement instances will have a 1..N containment relationship to function IOC instances. 
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6.1.3.3.2 



Attributes 



Table 6.4: Attributes of ManagedElement 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


managedElementId 


M 


M 


- 


dnPrefix 


M 


M 


- 


managedElementlype 


M 


M 


- 


userLabel 


M 


M 


M 


vendorName 


M 


M 


- 


userDefinedState 


M 


M 


M 


locationName 


M 


M 


- 


swVersion 


M 


M 


- 


managedBy 


M 


M 


- 



6.1.3.3.3 



Attribute constraints 



Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of ManagedElement is the 
local root instance of the MIB. Otherwise the attribute shall be absent or carry no information. 



6.1.3.3.4 



Notifications 



Table 6.5: Notifications of ManagedElement 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP {3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyAlarmListRebuilt 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyPotentialFaultyAlarmList 


See Alarm IRP {3GPP TS 32.111-2 [11]) 





6.1.3.4 



ManagedFunction 



6.1.3.4.1 



Definition 



This IOC is provided for sub-classing only. It provides attribute(s) that are common to functional lOCs. Note that a 
Managed Element may contain several managed functions. The ManagedFunction may be extended in the future if 
more common characteristics to functional objects are identified. 



6.1.3.4.2 



Attributes 



Table 6.6: Attributes of ManagedFunction 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


userLabel 


M 


M 


M 
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6.1.3.5 



ManagementNode 



6.1.3.5.1 



Definition 



This IOC represents a telecommunications management system (EM) within the TMN that contains functionality for 
managing a number of Managed Elements (MEs). The management system communicates with the MEs directly or 
indirectly over one or more interfaces for the purpose of monitoring and/or controlling these MEs. 

This class has similar characteristics as the ManagedElement. The main difference between these two classes is that the 
ManagementNode has a special association to the managed elements that it is responsible for managing. 



6.1.3.5.2 



Attributes 



Table 6.7: Attributes of ManagementNode 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


managementNodeld 


M 


M 


- 


userLabel 


M 


M 


M 


vendorName 


M 


M 


- 


userDefinedState 


M 


M 


M 


locationName 


M 


M 


- 


swVersion 


M 


M 


- 


managedElements 


M 


M 


- 



6.1.3.5.3 



Notifications 



Table 6.8: Notifications of ManagementNode 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (SGPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (SGPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (SGPP TS 32.1 1 1 -2 [1 1 ]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyPotentialFaultyAlarmList 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.6 



MeContext 



6.1.3.6.1 



Definition 



This IOC is introduced for naming purposes. It may support creation of unique DNs in scenarios when some MEs have 
the same RDNs due to the fact that they have been manufacturer pre-configured. 

If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same SubNetwork 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all IOC instances under those 
MEs. One way could be to set different DnPrefixes for those NEs, but that would require either that: 

a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 



b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. 
notifications. 



in alarm 



As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 
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MeContext have 0..N instances. It may exist even if no SubNetwork exists. Every instance of MeContext contains 
exactly one ManagedElement during steady-state operations. 



6.1.3.6.2 



Attributes 



6.1.3.6.3 



Table 6.9: Attributes of MeContext 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


meContextId 


M 


M 


- 


dnPrefix 


M 


M 


- 



Attribute constraints 



Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of MeContext is the local root 
instance of the MIB. Otherwise the attribute shall be absent or carry no information. 



6.1.3.6.4 



Notification 



Table 6.10: Notifications of MeContext 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (SGPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyPotentialFaultyAlarmList 


See Alarm IRP {3GPP TS 32.111-2 [11]) 





6.1.3.7 



SubNetwork 



6.1.3.7.1 Definition 

This IOC represents a set of managed entities as seen over the Itf-N. 

There may be zero or more instances of a SubNetwork. It shall be present if either a ManagementNode or multiple 
ManagedElements are present (i.e. ManagementNode and multiple ManagedElement instances shall have SubNetwork 
as parent). 

The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 
instance". 



6.1.3.7.2 



Attributes 



Table 6.1 1 : Attributes of SubNetwork 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


subNetworkId 


M 


M 


- 


dnPrefix 


M 


M 


- 


userLabel 


M 


M 


M 


userDefinedNetworkType 


M 


M 


- 
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6.1.3.7.3 



Attribute constraints 



Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of SubNetwork is the local 
root instance of the MIB. Otherwise the attribute shall be absent or carry no information. 



6.1.3.7.4 



Notification 



Table 6.12: Notifications of SubNetwork 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (SGPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyPotentialFaultyAlarmList 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





6.1.3.8 Top 



6.1.3.8.1 



Definition 



This IOC is introduced for generalisation purposes. All information object classes defined in all TS that claim to be 
conformant to 32.102[2] shall inherit from Top. 



6.1.3.8.2 



Attributes 



Table 6.13: Attributes of Top 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


objectClass 


M 


M 


- 


objectlnstance 


M 


M 


- 



6.1.3.9 



Class VsDataContainer 



6.1.3.9.1 



Definition 



The 'VsDataContainer' managed object is a container for vendor specific data. The number of instances of the 
'VsDataContainer' can differ from vendor to vendor. This IOC shall only be used by the Bulk CM IRP for the UTRAN, 
GERAN and CN NRMs. 



6.1.3.9.2 



Attribute 



Table 6.14: Attributes of VsDataContainer 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


vsDataContainerld 


M 


M 


- 


vsDataType 


M 


M 


- 


vsData 


M 


M 


M 


vsDataFormatVersion 


M 


M 


- 
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6.1 .4 Information relationship definitions 



6.1.4.1 



ManagementScope (M) 



6.1.4.1.1 



Definition 



This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manager and Subordinate. The role 'Manager' models the 
fact that a ManagementNode is responsible for managing zero or more MEs, and the role Subordinate models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the IOC definition mapped to a reference 
attribute with the same name. 



6.1.4.1.2 



Roles 



The roles involved in the relation ManagementScope are listed in this table. 

Table 6.15: Roles of the relation ManagementScope 



Name 


Definition 


Manager 


This role represents the ManagementNode's capability to identify the set of related ManagedElements. 
This role is modelled by a reference attribute named managedElements. 
IVIanagementNode.managedElements shall carry the set of ManagedElement DN(s). 


Subordinate 


This role represents the ManagedElements capability to identify the set of related 
managementNode(s). This role is modelled by a reference attribute named managedBy. 
ManagedElement.managedBy shall carry the set of ManagementNode DN{s). 



6.1.4.1.3 Constraints 

There is no constraint for this relationship. 
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6.1 .5 Information attribute definitions 
6.1 .5.1 Definitions and legal values 

Table 6.16 defines the attributes that are present in several information object classes of the present document. 

Table 6.16: Attributes 



Attribute Name 


Definition 


Legal Values 


dnPrefix 


It carries the DN Prefix information as defined in Annex C of 32.300 [13] 
or no information. 




managedElementId 


An attribute wliose 'name+value' can be used as an RDN when naming 
an instance of the l\/lanagedElement object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 




managedElementType 


The type of managed element. It is a multi-valued attribute with one or 
more elements. Thus, it may represent one ME functionality or a 
combination of more than one functionality. 

The actual syntax and encoding of this attribute is Solution Set specific. 


The legal values of this 
attribute are the names 
of the lOC(s) that are 
(a) derived/subclassed 
from IVIanagedFunction 
and (b) directly name- 
contained by 
IVIanagedElement IOC 
(on the first level below 
ManagedElement), but 
with the string 
"Function" excluded. 

The capitalisation 
(usage of upper/lower 
case) of characters in 
this attribute is 
insignificant. Thus, the 
IRPManager should be 
case insensitive when 
reading these values. 

Two examples of legal 
values are: 

• NodeB; 

• HLR,VLR. 


irpAgentId 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




iRPId 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




locationName 


The physical location of this entity (e.g. an address). 




managedElements 


l\/lodels the role 'IVIanager' - see subclause 6.1 .4.1 .2. This attribute 
contains a list of the DN(s) of the related IVIanagedElement instance(s). 




managementNodeld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




managedBy 


IVIodels the role 'Subordinate' - see subclause 6.1 .4.1 .2. This attribute 
contains a list of the DN(s) of the related ManagementNode 
instance(s). 




meContextld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




objectClass 


An attribute which captures the name of the class from which the object 
instance is an occurrence of. 




objectlnstance 


An information which captures the Distinguished Name of any object. 
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Attribute Name 


Definition 


Legal Values 


subNetworkId 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the SubNetwork object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 




swVersion 


The software version of the IVIanagementNode or IVIanagedElement 
(this is used for determining which version of the vendor specific 
information is valid for the ManagementNode or ManagedElement). 




systemDN 


The Distinguished Name (DN) of IRPAgent. Defined in 3GPP 
TS 32.300. 




userDefinedNetworkType 


Textual information regarding the type of network, e.g. UTRAN. 




userDefinedState 


An operator defined state for operator specific usage. (See also Note 
below) 




userLabel 


A user-friendly name of this object. 




vendorName 


The name of the vendor. 




vsData 


Vendor specific attributes of the type vsDataType. The attribute 
definitions including constraints (value ranges, data types, etc.) are 
specified in a vendor specific data format file. 




vsDataContainerld 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 




vsDataFormatVersion 


Name of the data format file, including version. 




vsDataType 


Type of vendor specific data contained by this instance, e.g. relation 
specific algorithm parameters, cell specific parameters for power 
control or re-selection or a timer. The type itself is also vendor specific. 
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Annex A (informative): 
lOC/IVIOC name recommendation 



Recommendation: 

3GPP considers the use of many non- alphanumeric characters as valid characters for constructing the IOC names. The 
Java programming language considers the use of alphanumeric characters plus only two non-alphanumeric characters, 
i.e. "$" and "_", as valid characters for Java Packages and Java Class names. Because the names of the Java Packages 
and Java Classes generated by Java programming tools for SS implementation may include MO Class names, a Java 
environment would have to include a translation mechanism that replaces the invalid characters (if they are used by the 
specification author to name an IOC, that is mapped to the same MOC name in a Solution Set) by valid characters. For 
example, replace "-" by "_". This translation mechanism causes unwanted complexity and reduction in performance of 
the implementation. Given Java may become popular for coding IRP Manager and/or IRP Agent capabilities, this note 
recommends the specification authors to use valid Java name characters (i.e. all alphanumeric characters plus "$" and 
"_") to name their IS lOCs and SS MOCs. 
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Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Jun 2001 


S 12 


SP-010283 


-- 


-- 


Approved at TSG SA #12 and placed under Change Control 


2.0.0 


4.0.0 


Sep 2001 


S_13 


SP-010479 


001 




Add the notification notifyComments in all MOCs that support 
alarms and correct the list of allowed members of the attribute 
managedElementType of the MOC managedElement 


4.0.0 


4.1.0 


Sep 2001 


S_13 


SP-010479 


002 


— 


Correction of Generic NRM Containment/Naming and Association 
diagram 


4.0.0 


4.1.0 


Sep 2001 


S 13 


SP-010479 


003 


-- 


Correct description of swVersion attribute 


4.0.0 


4.1.0 


Mar 2002 


S_15 


SP-020020 


004 


- 


Addition of managedElementType value for GSM Radio Access 
Network support 


4.1.0 


4.2.0 


Jun 2002 


S_16 


SP-020299 


005 


- 


Remove R99-inherited restriction of self-containment for MOC 
SubNetwork 


4.2.0 


4.3.0 


Sep 2002 


S 17 


SP-020488 


006 


-- 


Upgrade to Rel-5 (Add new IS method, MOC name convention) 


4.3.0 


5.0.0 


Jun 2003 


S 20 


SP-030280 


008 


-- 


Correction of Notifications for lOCs 


5.0.0 


5.1.0 


Dec 2003 


S_22 


SP-030643 


010 


— 


Add Missing VsDataContainer for ManagedFunction & 
ManagedElement and Other lOCs (Version 2) 


5.1.0 


5.2.0 


Dec 2003 


S 22 


SP-030644 


Oil 


-- 


Correction of UML diagram and other corrections 


5.1.0 


5.2.0 


Mar 2004 


S_23 


SP-040128 


013 


- 


Addition of missing attributes for the managementScope 
association 


5.2.0 


5.3.0 


Jun 2004 


S 24 


SP-040249 


015 


-- 


Add missing attribute constraints for dnPrefix 


5.3.0 


5.4.0 


Jun 2004 


S 24 


SP-040251 


017 


-- 


Correction of legal values for managedElementType attribute 


5.3.0 


5.4.0 
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